Skip to content

fix: Use ReturnType for more robust Chainable type#2098

Closed
dprevost-LMI wants to merge 1 commit intowebdriverio:mainfrom
dprevost-LMI:more-robust-chainable-typing
Closed

fix: Use ReturnType for more robust Chainable type#2098
dprevost-LMI wants to merge 1 commit intowebdriverio:mainfrom
dprevost-LMI:more-robust-chainable-typing

Conversation

@dprevost-LMI
Copy link
Copy Markdown
Contributor

In jest playgrounds, ChainablePromiseElement & ChainablePromiseArray had difficulty resolving properly due to a conflicting webdriverio version. Using ReturnType<WebdriverIO.Browser['$']> make it more reliable.

Why ReturnType<WebdriverIO.Browser['$']> fixed it:

  • It anchors the type to the consumer’s currently active WebdriverIO namespace instead of a separately imported webdriverio module.
  • So both sides of your matcher condition use the same type universe, and the extends checks succeed.

@greptile-apps
Copy link
Copy Markdown

greptile-apps Bot commented May 3, 2026

Greptile Summary

This PR changes the two local type aliases ChainablePromiseElement and ChainablePromiseArray from direct import('webdriverio').* references to ReturnType<WebdriverIO.Browser['$']> and ReturnType<WebdriverIO.Browser['$$']> respectively. The motivation is to anchor these types to the consumer's currently active WebdriverIO global namespace rather than a separately-resolved webdriverio module import, fixing extends check failures that surfaced in Jest playgrounds when a conflicting webdriverio version was present.

Confidence Score: 4/5

Safe to merge — the change is a targeted, well-motivated type-only fix with no runtime impact.

Only P2 findings present. The approach is sound and the PR description clearly explains the motivation. The one concern (ReturnType on overloaded methods) is a latent fragility rather than a present bug.

No files require special attention.

Important Files Changed

Filename Overview
types/expect-webdriverio.d.ts Two type aliases rewritten to use ReturnType from the global WebdriverIO namespace; logically sound but ReturnType on overloaded methods captures only the last overload, worth keeping in mind.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A["Consumer type-checks\nexpect(element)"] --> B{Which type source?}
    B -- "Before PR\n(direct import)" --> C["import('webdriverio').ChainablePromiseElement\n(may resolve different version)"]
    B -- "After PR\n(ReturnType)" --> D["ReturnType<WebdriverIO.Browser['$']>\n(same namespace as consumer)"]
    C --> E["⚠️ Type mismatch —\nextends check fails\n(version conflict)"]
    D --> F["✅ Same type universe —\nextends check succeeds"]
Loading

Reviews (1): Last reviewed commit: "Use `ReturnType` for more robust Chainab..." | Re-trigger Greptile

Comment on lines +11 to +12
type ChainablePromiseElement = ReturnType<WebdriverIO.Browser['$']>
type ChainablePromiseArray = ReturnType<WebdriverIO.Browser['$$']>
Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

P2 ReturnType on overloaded methods picks only the last overload

TypeScript's ReturnType resolves to the return type of the last overload signature when the target is an overloaded function. WebdriverIO.Browser['$'] and ['$$'] are typically overloaded (accepting string, Function, Element, etc.), so if any overload other than the last carries a different return type the alias would silently diverge from its intended meaning. In practice all overloads of $/$$ currently return ChainablePromiseElement/ChainablePromiseArray respectively, so this is not a bug today — but it's a subtle coupling to the ordering of WebdriverIO's internal overload declarations that could break silently if upstream changes them. A comment documenting this assumption would help future maintainers.

@dprevost-LMI dprevost-LMI marked this pull request as draft May 3, 2026 11:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant